Intrusion detection mechanism

ABSTRACT

In one embodiment, a method implemented on a node connected to a network bus includes: storing one or more message identifiers, the one or more identifiers comprising at least one message identifier identifying the node, the at least one message identifier being included in a message at a time when the message is sent by the node onto the network bus; monitoring network bus traffic, the network bus traffic comprising messages transmitted by the node and by other nodes connected to the network bus; and alerting a processor of the node if a message transmitted on the network bus by at least one of the other nodes is identified as having a message identifier corresponding to the at least one message identifier.

The present application is a continuation of U.S. patent applicationSer. No. 14/600,129, filed on 20 Jan. 2015.

TECHNICAL FIELD

The present disclosure generally relates to methods and apparatus todetect attacks on electronic control units of a vehicle.

BACKGROUND

Modern vehicles typically have a multiplicity of embedded systems calledElectronic Control Units (ECUs) configured to control one or more oftheir component electrical systems or sub-systems. For example, ECUs maybe used to control a vehicle's engine, transmission, brakes, suspension,etc. A vehicle may therefore be typically configured with dozens of suchECUs to control its operation. ECUs may typically communicate betweenthemselves using wired buses.

Most modern vehicles are also now equipped with a variety of wirelessinterfaces which increase their exposure/vulnerability to remote attacksby hackers and/or random interference from other wirelesscommunications. Typically, an attack on an ECU may be achieved using anyof its data connections (physical or wireless) and may consist ofexecuting malicious code to gain control of the ECU. The compromised ECUmay then be used as an entry point for the attack or further attackssuch as, for example, sending malicious or illicit messages to other(sensitive) ECUs.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood and appreciated more fully fromthe following detailed description, taken in conjunction with thedrawings in which:

FIG. 1A is a simplified pictorial illustration of an exemplary vehiclewith an intrusion detection component, constructed and operative inaccordance with an embodiment of the present invention;

FIG. 1B is a simplified pictorial illustration of an exemplary messagetransmitted over the communication network, constructed and operative inaccordance with an embodiment of the present invention, and

FIGS. 2 and 3 are simplified flow chart diagrams of alternative methodsfor alerting a processor of an anomaly detection in accordance withembodiments of the present invention.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

In one embodiment, a method implemented on a node connected to a networkbus includes: storing one or more message identifiers, the one or moreidentifiers comprising at least one message identifier identifying thenode, the at least one message identifier being included in a message ata time when the message is sent by the node onto the network bus;monitoring network bus traffic, the network bus traffic comprisingmessages transmitted by the node and by other nodes connected to thenetwork bus; and alerting a processor of the node if a messagetransmitted on the network bus by at least one of the other nodes isidentified as having a message identifier corresponding to the at leastone message identifier.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Reference is now made to FIG. 1A, which shows an exemplary vehicle withan intrusion detection component constructed and operative in accordancewith an embodiment of the present invention. A vehicle 100 is shown inFIG. 1A and typically comprises at least one vehicle's communication bus110 which is an internal communication network that interconnects aplurality of nodes 120 (hereinafter referred as Electronic Control Units(ECUs) 120) inside the vehicle. Examples of vehicle's communicationbuses typically include any type of Vehicle Area network such as, butnot limited to, CAN (Controller Area Network) defined in ISO11898-1:2003 and also described in greater detail inwww.ti.com/lit/an/sloa101a/sloa101a.pdf, LIN (Local InterconnectNetwork) described in further detail inen.wikipedia.org/wiki/Local_Interconnect_Network. FlexRay described infurther detail in en.wikipedia.org/wiki/FlexRay, etc. In the followingdescription, the communication bus 110 will be referred as the CAN bus110.

A plurality of ECUs 120 are coupled to the CAN bus 110. These ECUs 120are typically Electronic Control Units (ECUs) configured to control oneor more of their associated electrical systems or sub-systems.Non-limiting examples of such ECUs typically include, but are notlimited to including: engine control module (ECM); powertrain controlmodule (PCM); transmission control module (TCM); central control module(CCM); anti-lock braking system module (ABSM); central timing module(CTM); general electronic module (GEM); body control module (BCM);suspension control module (SCM); etc. Although described as separatemodules, it will be apparent to those skilled in the art that one modulemay incorporate a plurality of the control modules listed hereinabove.

Each ECU 120 typically comprises at least: a network interface 121; aCAN controller 122; and a host processor 123. The host processor 123 istypically a CPU (central processing unit) or microprocessor operable tointerpret the messages received from other components or sub-componentsof the vehicle (e.g. from other ECUs 120), and also to decide whichmessages to send out/transmit. Although not shown in FIG. 1A, the hostprocessor 123 may be connected to actuators, sensors, switches, or anyother appliances that the ECU 120 is configured to control.

The CAN controller 122, which may sometimes be integrated with the hostprocessor 123, is generally operable to receive messages from the CANbus 110 via the network interface 121 and pass the messages receivedfrom the host processor 123 to the network interface 121 for furtherdistribution via the CAN bus 110. The CAN controller 122 typicallycomprises a memory 124 for storing bits serially received from the CANbus 110 until an entire message is available. Once stored in memory 124,the message may be fetched by the host processor 123 for furtherprocessing. The memory 124 is also configured to storing a messagereceived from the host processor 123 that are to be transmitted to other(sub-) components of the vehicle 100. The CAN controller 122 typicallytransmits the message bits serially onto the CAN bus 110.

As mentioned above, the ECU 120 also comprises a network interface 121which is typically a CAN transceiver such as, but not limited to, a CANtransceiver defined by ISO 11898-2/3 Medium Access Unit standards. Inone embodiment, the role of the network interface 121 may be to driveand to detect data to and from CAN bus 110. Network interface 121converts the single-ended logic used by the CAN controller 122 to adifferential signal transmitted over the CAN bus 110. Network interface121 also determines a bus logic state from the differential signal orvoltage, rejects common-mode noise, and outputs a single-ended logicsignal to the CAN controller 122.

Each ECU 120 is operable to communicate with other ECUs 120 as necessaryvia the CAN bus 110. Some of the ECUs 120 form independent subsystemswhile others require exchanging data with other ECUs 120. Indeed, duringnormal operation of vehicle 100, an ECU 120 may need to controlactuators or receive feedback from one or more sensors through the CANbus 110. Communication between ECUs 120 is performed over the CAN bus110 using any suitable protocol and messaging system, as will beappreciated by those skilled in the art.

Each message sent and/or transmitted over the CAN bus 110 typically hasa pre-defined format comprising at least an identifier (ID) field and adata section (as shown in FIG. 1B), both of them including data producedby one sending ECU 120. The data section corresponds to the currentinformation that needs to be exchanged between a sending ECU (e.g. afirst ECU 120) and a receiving ECU (e.g. a second ECU 120). The ID fieldincludes a message ID which may be eleven or twenty-nine bits long inCAN networks. The message ID typically indicates the priority of themessage and is typically associated with a unique ECU 120. The messageID may therefore be used as an ID for identifying a particular ECU 120.In other words, the same message ID cannot be used by two different ECUs120 on the same CAN bus.

During normal operation, a CAN controller 122 of a particular ECU 120 istypically operable to read every message (i.e. every single bit) thatpasses on the CAN bus 110. The CAN controller 122 typically determineswhether or not a particular message has to be processed based on themessage ID. For example, when the CAN controller 122 receives a message,the message ID of the message may be used to determine whether or notthe message is relevant and/or interesting for the particular ECU 120.In such a situation, the CAN controller 122 alerts the host processor123 that a message has arrived. The message is then copied in a memory(not shown in FIG. 1A) of the host processor 123 space and processed.Otherwise, the message is ignored, that is to say not processed and theCAN controller 122 continues to monitor other messages transiting ontothe CAN bus 110. However, there are many ways attacks may beaccomplished once access to the CAN bus 110 is gained and/or when an ECU120 is compromised. For example, an attack may consist of impersonatinga particular ECU 120 for sending false messages to another ECU 120.Another similar example may consist of sending these false messages at ahigher rate than normal messages thereby saturating the CAN bus 110 andpreventing the normal messages from being received by some ECUs 120. Inboth cases, such attacks may either alter the proper functioning of thevehicle 100 or have a harmful effect on the passengers and/or thevehicle 100.

In an exemplary embodiment of the present invention, the CAN controller122 further comprises an intrusion detection component 125 which is ableto detect such attacks. Typically, the intrusion detection component 125(IDC) is operable to monitor the CAN bus 110 to detect anomaliesappearing in different messages forming the CAN bus traffic. An IDC 125may be incorporated into each CAN controller 122 of each ECU 120,thereby enabling each ECU 120 to individually analyze the messages onthe CAN bus 110 and detect anomalies in a cheap and efficient manner ata hardware and/or firmware level. Whenever an IDC 125 of an ECU 120detects an anomaly, the CAN controller 122 alerts the host processor 123which then take remedial or protective actions. Additionally and/oralternatively, an interrupt signal may be generated by the IDC 125 andsent to the host processor 123 if the latter is able to handle suchinterrupts. As a result, different actions may be taken depending on theECU 120 that has detected the anomaly. For example, a visual indicationmay be displayed on the vehicle's front panel thereby alerting thedriver that something is going wrong. Another example may be to recordthe detected anomaly and store it in a non-volatile memory so that amechanic may be notified at the time when the vehicle is being repairedor checked. further non-limiting example available for connectedvehicles may be to send an alert to a cal center or a central serverexternal to the vehicle 100 in order to receive assistance regarding theissue in a (near) real-time fashion or even at a later time afterfurther analysis of the alert(s) by the central/call center.

Reference is now made to FIG. 2, which is a simplified flow chartdiagram illustrating a method for alerting a processor of an ECU of ananomaly detection in accordance with an embodiment. In an exampleembodiment, the IDC 125 is configured to detect anomalies associatedwith messages sent by an ECU 120 using the message IDs. At step 200, theIDC 125 stores the message IDs used by the host processor 123 of the ECU120 for sending messages to other ECUs 120 via the CAN bus 110. Themessage IDs may be stored in any suitable manner in a memory (not shownin FIG. 1A) of the IDC 125 or the CAN controller 122. The message IDsmay be either provided to the IDC 125 directly by the host processor 123of the ECU 120 or dynamically extracted by the IDC 125 at the time whenmessages are sent by the ECU 120. In the latter case, when a message isto be sent by the ECU 120 to another ECU 120 through the CAN bus 110,the host processor 123 of the ECU 120 typically prepares and transmitsthe message to its CAN controller 122. The message is received by theCAN controller 122 which stores it in its memory 124 prior totransmitting the bits serially onto the CAN bus 110 via the networkinterface 121. At the time when the message is being stored into thememory 124, the IDC 125 is configured to extract the message ID from themessage, and to record the message ID. The IDC 125 is further configuredto monitor the CAN bus traffic (step 210) and identify messagestransiting onto the CAN bus 110 which have a message ID matching one ofthe recorded message IDs (step 220) and which were sent by other ECUs120. When such a message is identified on the CAN bus 110 at step 230,this is an anomaly indicating that the CAN network of the vehicle 100 isbeing attacked. This typically means that false messages impersonating aparticular ECU 120 are present onto the CAN bus 110. As a result, theIDC 125 detects this anomaly (step 230) and alerts and/or sends aninterrupt signal to the host processor 123 at step 240.

Reference is now made to FIG. 3, which is a simplified flow chartdiagram illustrating an alternate method for alerting a processor of anECU of an anomaly detection in accordance with an embodiment. In anotherfurther example embodiment, the intrusion detection component 125 isconfigured to detect anomalies associated with messages sent by an ECU120 using the message IDs and an expected delta time at which suchmessages are sent. In normal CAN network configurations, there is aparticular delta time or time interval associated with messages sentand/or received by particular ECUs 120. For example, a messagecorresponding to the number of rounds per minute (RPM) of the vehicle'sengine is sent at very regular intervals (e.g. every ten milliseconds)and is to be sent by the ECM and received by the TCM. Therefore, at step300, the IDC 125 of an ECU 120 is operable to store one or more messageIDs along with their expected delta times at which subsequent messagescarrying the same type of information (i.e. having a same message ID)are expected to be observed on the CAN bus 110. As explained hereinabovein relation to the method of FIG. 2, the message IDs and the expecteddelta times may be stored in any suitable manner in a memory (not shownin FIG. 1A) of the IDC 125 or the CAN controller 122. In a situationwhere the messages correspond to messages sent and/or received by theECU 120, the message IDs and the expected delta times may be eitherprovided directly to the IDC 125 by the host processor 123 ordynamically extracted/calculated by the IDC 125 at the time whenmessages are sent or read by the ECU 120. Furthermore, the ECU 120 mayalso be operative to implement the method for messages that simplytransit onto the CAN bus 110 i.e. messages that need not to be processedby the ECU 120. In the latter case, the message IDs and the expecteddelta times may be provided to the IDC 125 by the host processor 123 orfrom an external source. In any case, the IDC 125 of the ECU 120 isfurther operable to monitor the CAN bus traffic (step 310) foridentifying messages having message IDs matching one of the recordedmessage IDs (step 320). Once such a message IDs identified at step 320,the IDC 125 is operable to determine a delta time at which the messageis observed on the CAN bus 110 (step 330). To do so, the IDC 125retrieves a present time, typically corresponding to the time at whichthe message was observed, and determines a present delta time. Thepresent delta time corresponds to the time difference between thearrival of the present message and the arrival of the last messagehaving a same specific message ID. Then, the present delta time iscompared to the expected delta time stored in the memory. At step 340,the IDC 125 is therefore able to detect an anomaly if the present deltatime does not match the expected delta time. In such a situation, thisis an anomaly that may be indicating that the CAN network of the vehicle100 is being attacked. This typically means that false messages are sentin order to saturate the CAN bus 110 or that counterfeit messages arebeing sent out onto the CAN bus 110. As a result, the IDC 125 alertsand/or sends an interrupt signal to the host processor 123 (step 350).

In an example implementation of the alternate anomaly detection methodof FIG. 3, the IDC 125 typically includes a counter which is incrementedat fixed intervals (e.g. every millisecond). During normal operation,the following information is stored in the memory and available to theIDC 125 for each message ID relevant to the ECU 120:

-   -   C_(p): counter value at the time when the previous message was        observed on the CAN bus 110, and    -   Δt_(ref): reference delta time provided by the host processor        123.

When a message is observed on the CAN bus 110 and read by the CANcontroller 122, the message ID is extracted and the IDC 125 uses thepresent value of the counter C_(c) to compute the present delta timeΔt_(c) (i.e. time interval at which two consecutive message with thesame message ID are observed on the CAN bus 110) as follows:

Δt _(c) =C _(c) −C _(p)

The present computed delta time (Δt_(c)) is then compared to thereference delta time (Δt_(ref)). The reference delta time (Δt_(ref)) istypically provided as a range and the present computed delta time(Δt_(c)) is compared to the upper and lower boundaries. These upper andlower boundaries typically correspond to maximum and minimum delta timesor time intervals at which two consecutive messages having a samemessage ID can be observed onto the CAN bus 110 in normal operation. Ifthe present computed delta time (Δt_(c)) is more than the maximumreference delta time and/or is less than the minimum reference deltatime, then an alarm signal is generated and sent to the host processor123. Subsequently, whether or not an alarm signal has been generated,the C_(p) value is updated i.e. set to the current value C_(c) andstored in memory. Those skilled in the art will appreciate that themaximum and minimum reference delta times may not be available or knownthereby preventing the host processor 123 for providing them to the IDC125. In such a situation, default values may be used by the IDC 125 suchas for example zero for the minimum reference delta time and positiveinfinity for the maximum reference delta time.

Additionally and/or alternatively, a previous computed delta time(Δt_(p)) is stored in memory and is available to the IDC 125 for eachmessage ID relevant to the ECU 120. The previous computed delta time(Δt_(p)) may correspond, for example, but not limited to, to the timedifference between the time at which the second last message wasobserved and the time at which the last message was observed. Thepresent computed delta time (Δt_(c)) is then compared the previouscomputed delta time (Δt_(p)) which is therefore used as the expecteddelta time or as an additional expected delta time if the presentcomputed delta time (Δt_(c)) was first compared to the reference deltatime (Δt_(ref)). If the present computed delta time (Δt_(c)) isdifferent from the previous computed delta time (Δt_(p)) or if adifference (in absolute value) between the present computed delta time(Δt_(c)) and the previous computed delta time (Δt_(p)) exceeds apredefined and configurable threshold, an alarm signal is generated andsent to the host processor 123. Subsequently, the C_(p) value is updatedi.e. set to the current value C_(c) and stored in memory. Also, thepresent computed delta time (Δt_(c)) is stored in memory in place of theprevious computed delta time (Δt_(p)).

Those skilled in the art will appreciate that the method described inthe previous paragraphs may be achieved using a single counter. However,in another example, a plurality of counters may be provided typicallyone counter per type of messages (message ID) that the IDC 125 isinstructed to monitor. In the latter case, the present delta time isdetermined directly by using the counter present value. The counterpresent value used for the delta time determination is then reset tozero. The other method steps remain unchanged.

The alarm signal may be a direct and/or an interrupt signal generatedand sent by the IDC 125 to the host processor 123. Additionalinformation may further be associated with the direct and/or interruptsignals during the generating step to indicate to the host processor 123that a type of detected anomaly or merely that an anomaly has beendetected. Another exemplary way to alert the host processor 123 of thedetected anomaly may be to wait for the host processor 123pulling/sampling the contents of the received message from the CANcontroller 122. Upon detection of an anomaly, the IDC 125 may beoperable to add few “alerting” bits into the original message indicatingthe detection and type of anomaly. Then, when the host processor 123processes the message transmitted from the CAN controller 122, it isalerted of the attack and may take some remedial or protective actions.

By implementing such a method, the host processor 123 may be alertedwhenever a change in the delta time at which messages having a specificID are observed on the CAN bus 110 occurs. However, those skilled in theart will appreciate that the delta time at which certain messages aretransmitted and/or received at some ECUs 120 may change over time aspart of the normal operation of the vehicle 100. Taking again theexample of the number of rounds per minute of the vehicle's engine, thecorresponding message, although initially transmitted every tenmilliseconds, may then be transmitted every five milliseconds undercertain circumstances but still as part of the normal operating mode ofthe vehicle 100. In this case, the IDC 125 may be informed directly bythe host processor 123 of such a change or may update the expected deltatime in the memory after having observed two or more consecutivemessages with such new delta time. However, in order to avoid falsealarms due to such delta time changes, the IDC 125 may generate and sendan alarm signal only when repetitive anomalies are detected (e.g. for acertain number of consecutive messages; and/or for a certain number ofmessages during a pre-defined period of time; etc.). Conversely, the IDC125 may generate and send the alarm signal whenever an anomaly isdetected while the host processor 123 is configured to take remedial orprotective actions only if it receives repetitive alarm signals (e.g. acertain number of consecutive alarm signals and/or a certain number ofalarm signals received during a pre-defined period of time) from the IDC125.

It is appreciated that software components of the present invention may,if desired, be implemented in ROM (read only memory) form. The softwarecomponents may, generally, be implemented in hardware, if desired, usingconventional techniques. It is further appreciated that the softwarecomponents may be instantiated, for example: as a computer programproduct or on a tangible medium. In some cases, it may be possible toinstantiate the software components as a signal interpretable by anappropriate computer, although such an instantiation may be excluded incertain embodiments of the present invention.

It is appreciated that various features of the invention which are, forclarity, described in the contexts of separate embodiments may also beprovided in combination in a single embodiment. Conversely, variousfeatures of the invention which are, for brevity, described in thecontext of a single embodiment may also be provided separately or in anysuitable subcombination.

It will be appreciated by persons skilled in the art that the presentinvention is not limited by what has been particularly shown anddescribed hereinabove. Rather the scope of the invention is defined bythe appended claims and equivalents thereof:

1. method implemented on a node connected to a network bus, said methodcomprising: storing one or more message identifiers, said one or moreidentifiers comprising at least one message identifier identifying saidnode, said at least one message identifier being included in a messageat a time when said message is sent by said node onto said network bus;monitoring network bus traffic, said network bus traffic comprisingmessages transmitted by said node and by other nodes connected to saidnetwork bus; and alerting a processor of said node when a messagetransmitted on said network bus by at least one of said other nodes isidentified as having a message identifier corresponding to said at leastone message identifier.
 2. The method of claim 1, wherein: said storedone or more identifiers comprises at least one message identifieridentifying at least one node connected to said network bus, said atleast one message identifier being included in a message at a time whensaid message is sent by said at least one node onto said network bus;said storing further comprises: storing an expected delta time alongwith said at least one message identifier identifying said at least onenode, said expected delta time corresponding to a time differenceassociated with times at which two consecutive messages including saidat least one message identifier are expected to be observed on saidnetwork bus; said method further comprising: determining a present deltatime for a present message of said network traffic having said stored atleast one message identifier, said present delta time corresponding to atime difference associated with times at which said present message anda last message having said stored at least one message identifier areobserved on said network bus; and said alerting comprises alerting aprocessor of said node when said determined present delta time isdifferent from said stored expected delta time.
 3. The method of claim2, wherein said stored expected delta time comprises a maximum deltatime and a minimum delta time; and said alerting comprises alerting theprocessor of said node when said determined present delta time is morethan said maximum delta time or is less than said minimum delta time. 4.The method of claim 2, wherein a previously determined delta time isused as said stored expected delta time.
 5. (canceled)
 6. The method ofclaim 2, wherein said stored expected delta time comprises a maximumdelta time, a minimum delta time and a previously determined delta time;and said alerting comprises alerting the processor of said node when oneor more of the following conditions is met: said determined delta timeis more than said maximum delta time; said determined delta time is lessthan said minimum delta time; a difference, in absolute value, betweensaid determined present delta time and a previously determined deltatime exceeds a predefined threshold.
 7. The method of claim 2, whereinsaid determining comprises: retrieving a first time value from a counterof said node, said first time value corresponding to a time at whichsaid present message is observed on said network bus; retrieving asecond time value from a memory of said node, said second time valuecorresponding to a time at which said last message was observed on saidnetwork bus; and determining a present delta time by computing a timedifference between said first and second time values.
 8. The method ofclaim 7, further comprising: after said retrieving a second time value,storing said first time value in said memory in place of said secondtime value.
 9. The method of claim 2, wherein said determiningcomprises: providing one or more counters at said node, each counterbeing associated with a single message identifier; retrieving a timevalue from a counter associated with said at least one messageidentifier, said time value corresponding to a time at which saidpresent message is observed on said network bus; and determining apresent delta time by using said retrieved time value.
 10. The method ofclaim 9, further comprising: resetting said counter to zero after havingdetermined said present delta time.
 11. The method of claim 2, whereinsaid alerting further comprises: generating an alarm signal when saiddetermined delta time is different from said expected delta time; andsending said generated alarm signal to said processor of said node. 12.The method of claim 11, wherein said alarm signal is generated and sentto said processor whenever said determined delta time is different fromsaid expected delta time.
 13. The method of claim 11, wherein said alarmsignal is generated and sent to said processor when a certain number ofdetermined delta times for a certain number of messages having said atleast one message identifier are different from said expected deltatime.
 14. The method of claim 11, wherein said alarm signal is generatedand sent to said processor when a certain number of determined deltatimes for messages having said at least one message identifier aredifferent from said expected delta time during a predefined period oftime.
 15. The method of claim 11, wherein said alarm signal comprises aninterrupt signal associated with additional information, said additionalinformation indicating a type of detected anomaly.
 16. The method ofclaim 11, wherein: said generating comprises: retrieving said presentmessage; and inserting additional bits in said retrieved presentmessage, said additional bits indicating to said processor a type ofdetected anomaly; and said sending comprises sending said retrievedpresent message including said inserted additional bits to saidprocessor of said node.
 17. A node connected to a network bus, said nodecomprising: a network interface; a processor; and a controller; whereinsaid controller further comprises an intrusion detection componentoperable to: store one or more message identifiers, said one or moremessage identifiers comprising at least one message identifieridentifying said node, said at least one message identifier beingincluded in a message at a time when said message is sent by said nodeonto said network bus; monitor network bus traffic, said network bustraffic comprising messages transmitted by said node and by other nodesconnected to said network bus; and alert said processor when a messagetransmitted on said network bus by at least one of said other nodes isidentified as having a message identifier corresponding to said at leastone message identifier.
 18. The node of claim 17, wherein said intrusiondetection component is further operable to extract said at least onemessage identifier from a message received from said processor of saidnode that is to be transmitted onto said network bus.
 19. The node ofclaim 17, wherein said stored one or more identifiers comprises at leastone message identifier identifying at least one node connected to saidnetwork bus, said at least one message identifier being included in amessage at a time when said message is sent by said at least one nodeonto said network bus; and said intrusion detection component beingfurther operable to: store an expected delta time along with said atleast one message identifier identifying said at least one node, saidexpected delta time corresponding to a time difference associated withtimes at which two consecutive messages including said at least onemessage identifier are expected to be observed on said network bus;determine a present delta time for a present message of said networktraffic having said stored at least one message identifier, said presentdelta time corresponding to a time difference associated with times atwhich said present message and a last message having said stored atleast one message identifier are observed on said network bus; and alertsaid processor when said determined present delta time is different fromsaid stored expected delta time.
 20. The node of claim 19, wherein saidexpected delta time is provided by said processor.